[00:00] In this lesson, we'll demonstrate how to perform any desired actions when a vision client starts up by using a client event startup script, The client's startup script runs every time a client is launched, logic is run right after login, so after a user logs in successfully, the startup script will run. We can access this by going to the project menu in our designer, selecting the client events option, and then the first option is startup, which is open here. One very simple demonstration might be to just display a gooey pop-up upon startup. Here on line two, we'll just use system.gooey.message box, to display a message that the client is starting up, like so. For now, we'll just click apply to save any changes and keep this window open. To see this in action, all we need to do is login to our vision client, which I'll bring to the foreground. And then upon any valid login, such as perhaps admin, we'll see the pop-up up here like so.

[01:12] But this isn't particularly interesting since all we have right now is a simple empty client with no starting Windows yet. So let's dismiss this pop-up, the logout, minimize our client once again and show something a bit more useful. Another typical usage of the startup might be to open up a custom set of Windows. Maybe the opening Windows should differ based upon who has logged in. For example, you might customize the starting client Window based on a user's role or even by specific usernames. So let's first return to our client's startup Window. And now, let's comment out this first example, like so, and then uncomment this next example by selecting this range and clicking control slash to uncomment. Now, let's imagine we want our users to see different start-up Windows when they log into their shared vision client.

[02:11] For example, over on the left in our project browser, in the main Windows, we have an admin start-up Window, and we can see we have various logins already defined based on roles and users already defined in our gateway. We've got an administrator account and operator named Bob, and a visitor role for a guest username. So maybe we'd want our admin to be able to manage all these user accounts. Then here's an operator start-up Window, and we can imagine wanting anyone who's an operator to do operator type things. And finally, here's a visitor start-up Window. We might just want any visitors to feel welcomed, stay safe, and acknowledge reading this disclaimer Window. The actual content of these three Windows is not all that important.

[03:05] What matters is that they are all distinct and specific to different user roles. So what we wanna do is login with three different user credentials and see different Windows displayed based upon that user's role, is defined back in our gateway and was also shown in our admin Window here. So all these things can be handled by our start-ups script. Here on line five, we will get the username at login, and then we will use that on the next line to get the users roles, assuming a default user source as the first input here, user roles is a Python string sequence. So in these next lines, in the NFL's, using in, we can check if a certain role is assigned to a user. We'll open up the appropriate Window using system.nav.openwindow, based upon that user's role. Notice that we're checking the highest role first, for example, if a user has all of these roles assigned, we might want them to have the highest role possible by checking that first.

[04:16] To see all of this in action, let's once again apply the changes, save here at the upper left to push our changes out to the gateway. And then we'll try logging into our vision client, which I'll bring back up again using three different users. So we're already logged out, and if we login as the admin like so, we'll be greeted by the admin Window, and if we logout and login as Bob, who is an operator, Bob will begin at the operator start-up Window. And if we logout one more time and log back in as the guest who is a visitor, we're then greeted by this startup Window for the visitor.

[05:17] The only thing to really be aware of for the client's startup script, is that if you're trying to do something like, logging right back out or retargeting, which means switching over to an entirely new project, you should allow that action to complete first and then perform the specified start-up action using an invoke later. For example, let's say that under certain circumstances, I want it to log the user immediately back out. So, once again, we will comment out the prior example using control/once more. And then we'll uncomment this last example. In here, I'm going to use a system.security.logout, that I will put this system call into a defined function call like so, which I can call later on by name using system.util.invoke later.

[06:15] The reason to do this is, because the startup script is run during the client's startup, it's better for the system to logout after all that startup stuff is finished. That's what invoke later does, it runs a function after the current event processing has finished. So to wrap up, in this lesson we've seen a couple different ways of putting a client startup script to practical use.